This is an experiment to see if I can keep up with
doing post-release version bumps, so git snapshots
will always have a different version from released
tarballs.
"left of right" should be "left or right".
There's a small (subjective?) English nit in there as well: I believe
that buttons are placed (for example) "on the right" rather than "at the
right".
There is nothing particularly specific to drawables
in there (and we don't have that concept anymore),
so just name the source file to match the header.
Easier for everybody.
Carlos Garnacho [Sat, 24 Sep 2022 09:45:18 +0000 (11:45 +0200)]
gtkimcontextwayland: Shuffle full resets after IM changes
Doing reset() on the text widgets after commit and delete_surrounding
is still too eager for some IMs (e.g. those that expect being able
to commit text while keeping a preedit buffer shown).
However, reset() is more of a "synchronize state" action on Wayland,
and it is still desirable to do that after changes that do come from
the IM (e.g. requesting the new surrounding text and cursor/anchor
positions). Notably here, the text_input protocol may still come up
with a preedit string after this state synchronization happens.
Shuffle the code so that the text widgets do not reset() the IM
context after text is deleted or committed, but the Wayland IM does
apply its practical effects after these actions happen. This keeps
the Wayland IM fully up-to-date wrt text widget state, while not
altering the ::commit and ::delete-surrounding-text behavior for
other IM context implementations.
Closes: https://gitlab.gnome.org/GNOME/gtk/-/issues/5200 Fixes: 5b78fe2721 (gtktextview: Also reset IM context after IM...) Fixes: 7c0a395ff9 (gtktext: Also reset IM context after IM...) Fixes: 52ac71b972 (gtktextview: Shuffle the places doing IM reset) Fixes: 9e29739e66 (gtktext: Shuffle the places doing IM reset)
Introduce GDK_DISPLAY_DEBUG() and GDK_DEBUG() and
the helper function gdk_debug_message(). This is
meant to clean up the mess of our current debug
statements which wildly mix g_message, g_print
and g_printerr.
Carlos Garnacho [Fri, 23 Sep 2022 11:45:46 +0000 (13:45 +0200)]
gtkgesture: Do not update gestures with mismatching n-points on touchpad
Check that the touchpad gesture event has a matching number of fingers before
updating the GtkGesture point tracking, instead of afterwards. Avoids pointless
tracking of these touchpad events when we know beforehand that the gesture
will never be activated by the touchpad events.
The old wiki page has a couple issues:
* It's out-of-date, not having any notes for GTK4 specifically,
and it doesn't link to `gvsbuild`, which (I believe) is
the current official (and best) way to build GTK with MSVC.
* It's "locked", so it's harder for contributors to update. This
is OK, except for one spicy detail:
* It's not clear how to contribute/report issues on the locked wiki
pages, so out-of-date information falls off the radar.
Regardless :) the gtk.org GTK for Windows docs are a much better
springboard, in my opinion.
Michal Vasilek [Sun, 18 Sep 2022 18:48:21 +0000 (20:48 +0200)]
build: fix gi-docgen detection in cross builds
gi-docgen is supposed to be ran natively on the build machine, without
native: true dependency() searches for gi-docgen on the host system.
When it doesn't find it, it falls back to a subproject even if gi-docgen
is available on the build machine.
Simon McVittie [Sat, 17 Sep 2022 20:50:38 +0000 (21:50 +0100)]
build: Use more conservative GResource embedding on non-x86_64
Doing clever things with objcopy is faster and seems to be reliable on
x86_64 Linux, but also doesn't work on all toolchains and architectures:
in particular, Debian has had trouble with this on arm and mips.
In a distro build environment where we are compiling all of GTK every
time, the cost of potentially unreliable builds is higher than the cost
of using slower but more conservative GResource embedding.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5107 Signed-off-by: Simon McVittie <smcv@debian.org>
Simon McVittie [Sat, 17 Sep 2022 17:53:00 +0000 (18:53 +0100)]
gdkevents: Don't ignore modifiers that are not currently active
The X11 backend can mark modifiers like Shift as consumed even if they
aren't actually active, which seems to be something to do with making
shortcuts like `<Control><Shift>plus` and `<Control>plus` work as
intended regardless of whether the plus symbol is obtained by pressing
Shift and a key (like `+/=` on American, British or French keyboards)
or not (like `*/+` on German keyboards).
However, this can go badly wrong when the modifier is *not* pressed.
For example, terminals normally have separate bindings for `<Control>c`
(send SIGINT) and `<Control><Shift>c` (copy). If we disregard the
consumed modifiers completely, when the X11 backend marks Shift as
consumed, pressing Ctrl+c would send SIGINT *and* copy to the clipboard,
which is not what was intended.
By masking out the members of `consumed` that are not in `state`, we
get the same interpretation for X11 and Wayland, and ensure that
keyboard shortcuts that explicitly mention Shift can only be triggered
while holding Shift. It continues to be possible to trigger keyboard
shortcuts that do not explicitly mention Shift (such as `<Control>plus`)
while holding Shift, if the backend reports Shift as having been
consumed in order to generate the plus keysym.
Resolves: https://gitlab.gnome.org/GNOME/gtk/-/issues/5095
Bug-Debian: https://bugs.debian.org/1016927 Signed-off-by: Simon McVittie <smcv@debian.org>
projects / gtk4.git / log